gh-129817: Use _PyType_HasFeature() to check tp_flags.
#130892
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the free-threaded build, an atomic load is needed to safely read
tp_flags, avoiding data races. Replace bit tests ontp->tp_flagswith calls to_PyType_HasFeature(). When multiple bits are being returned as a result of the test, usePyType_GetFlags().I think some of these flag tests can safely be a normal load rather than an atomic load. However, it seems better to consistently use
_PyType_HasFeature()unless we are sure there is no data race possible.Implementation notes:
tp_flagsdirectly. I used this command to find all the places:rg -tc -- '->tp_flags \&'and then used editor macros to make the changes._PyType_HasFeature()are not always equivalent since the function only returns 0 and 1 while the test expression might care about individual bits. I wrote a replacement_PyType_HasFeaturefunction that checks how many bits are being passed as the feature and then ensured that only one bit is set. I then manually fixed or confirmed cases were this wasn't so. So, I'm fairly sure using_PyType_HasFeature()as this PR does is correct in all cases.Related PRs: gh-120210 gh-127588
tp_flagswith subinterpreters and static types #129817